AD - IT Policy and Network Shares

Scenario

With the sales team policy in place, NetLab LLC now wants to set up a dedicated network drive for the IT department. This drive will allow IT staff to read and write files from any domain joined workstation on the network. The drive should be mapped automatically when an IT user logs in and should not be visible or accessible to any other department. No manual setup should be required on the workstation side.

Environment

• Proxmox
• Network Lab LAN
• NetLab.private
• Target: IT staff members only
• Domain Controller: DC01

Creating the Shared Folder on DC01

The first step is to create the folder on the domain controller that will serve as the storage location for the shared drive. Navigate to the C: drive on DC01 and create a folder for the drive. I chose C:\Shares\IT_Share. The parent folder called Shares is simply an organizational choice to keep all future shared folders in one place. It has no effect on how the share is exposed to the network.

Once the folder exists, it needs to be shared so that other machines on the network can reach it. Right-click the IT_Share folder, open Properties, go to the Sharing tab, and click Advanced Sharing. Check the box to share the folder and set the share name to IT_Share. Under Permissions, grant the IT staff group at minimum read and write access. The network path will then become \\DC01\IT_Share.

Creating the GPO and Configuring Security Filtering

Open GPMC and right-click the IT OU, then select Create a GPO in this domain, and Link it here. I named the new policy POL_ITRestrictions. This creates the policy and links it to the IT OU in one step.

Since this drive map should only go to IT staff, we need to narrow that down using Security Filtering. Click on POL_ITRestrictions in GPMC, go to the Scope tab, and look at the Security Filtering section at the bottom. Remove Authenticated Users from the list, then click Add and enter GRP_IT_Staff. This tells the policy to only apply to members of that group, even if other user accounts exist in the same OU.

Configuring the Drive Map

Right-click POL_ITRestrictions and select Edit to open the policy editor. Navigate to User Configuration → Preferences → Windows Settings → Drive Maps. Right-click inside the panel and select New, then Mapped Drive. Set the Action to Create, enter \\DC01\IT_Share as the location, and assign drive letter Z.

Once saved, run gpupdate /force on the workstation and then log out and log back in as an IT staff member. The Z: drive should appear automatically in File Explorer without any manual mapping needed.

Verifying the Policy

After logging back in as Alice, an IT staff member, open PowerShell and run the following command to generate a full policy report:

gpresult /h C:\Users\aadams\Desktop\gpresult.html

Open the report in a browser and check the Applied GPOs section under User Details. The POL_ITRestrictions policy should appear there, and the Z: drive should be visible in File Explorer. To confirm the policy is not leaking to other departments, log in as either a sales team member or any other member who isn't in the IT OU and verify that no Z: drive appears for them. This command was a big help in problem solving fast link issues.

Problems Encountered

This lab had more troubleshooting than expected, and most of it came down to two separate issues that were not immediately obvious from the error messages alone.

The first issue was with group membership not being reflected in Alice's (IT OU) active session. After adding her to GRP_IT_Staff, gpresult showed her correct OU location but the policy still was not applying. Running whoami /groups on the workstation revealed that GRP_IT_Staff was not listed in her session at all, even though she was confirmed as a member in Active Directory. This happened because Windows builds a user's group membership list at logon and does not update it mid-session. A full log out and log back in was required to refresh her security token and pick up the new group membership.

The second and more significant issue was caused by the virtualized network environment in Proxmox. Even after confirming that the policy was correctly configured, linked, and filtered, the gpresult report showed no applied GPOs and displayed a warning that a fast link had been detected.

gpresult report showing no applied GPOs and the fast link detection warning that was blocking Group Policy Preferences from processing

Windows measures the speed of the connection between the workstation and the domain controller during policy processing. If it considers the connection too slow, it skips processing Group Policy Preferences entirely, which includes Drive Maps. Because Proxmox introduces enough network overhead to trip that threshold, the drive map was being silently skipped every time, even though the rest of the policy configuration was correct.

The fix required two changes inside the GPO editor under Computer Configuration → Policies → Administrative Templates → System → Group Policy. First, Group Policy Caching was disabled to prevent stale cached versions of policies from interfering. Second, Configure Group Policy slow link detection was set to Enabled with a connection speed value of 0. Setting the threshold to zero tells Windows to treat any connection as fast, which prevents the slow link check from ever blocking policy processing.

The Configure Group Policy slow link detection setting inside the Group Policy Management Editor, highlighted during the fix

After applying both settings to the workstation OU and running a full reboot on WS01, the Z: drive appeared correctly for Alice on her next login. The same drive did not appear for users outside the IT department, confirming the Security Filtering was working as intended.

Closing Notes

This lab covered a lot more ground than just mapping a drive. The troubleshooting process revealed two important concepts that do not always get explained clearly in documentation. The first is that group membership only becomes active in a user session at the point of login. Changes made to a group in Active Directory will not take effect for a currently logged in user until they fully sign out and back in. Running gpupdate alone is not enough.

The second concept is the difference between Group Policy settings and Group Policy Preferences. Regular policy settings apply regardless of network conditions. Preferences, which include things like Drive Maps, are treated differently and can be silently skipped if Windows decides the connection to the domain controller is too slow. In a real environment this is rarely a problem, but in my virtualized lab, it caused a lot of confusion because everything looks configured correctly and the only error that appeared was the easy to miss "Fast Link" warning at the top of the gpresult.

It is also worth noting the difference between a local folder path and a network share path. The two are completely independent. The share name is what gets exposed to the network, and the folder structure behind it stays invisible to connecting clients.

Finally, the slow link fix applied here (disabling caching and setting the threshold to zero) is appropriate for a lab environment where you need fast and reliable policy updates. In an enterprise environment, these settings should be reviewed carefully before applying them, since they remove safeguards that exist for good reasons in larger or more distributed networks.